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A family of unimplemented computing languages is de- 
scribed that is intended to span differences of application area 
by a unified framework. This framework dictates the rules 
cbout the uses of user-coined names, and the conventions 
about characterizing functional relationships. Within fhis frame- 
work the design of a specific language splits into two inde- 
pendent parts. One is (he choice of written appearances of 
programs (or more generally, their physical representation). 
The o:her is the choice of the abstract entities (such as numbers, 
character-strings, lists of them, functional relations among 
them) that can be referred to in the language. 

The system is biased towards "expressions" rather than 
"statements." It includes a nonprocedural (purely functional) 
subsystem (hat aims to expand the class of users' needs that 
can be met by a single print-instruction, without sacrificing the 
important properties that make conventional right-hand-side 
expressions easy to construct and understand. 

1. Introduction 

Most programming languages are partly a way of 
expressing things in terms of other things and partly a 
basic set of given things. The Iswim (If you See What I 
Mean) system is a byproduct of an attempt to disentangle 
these two aspects in some current languages. 

This attempt has led the author to think that many 
linguistic idiosyncracies are concerned with the former 
rather than the latter, whereas aptitude for a particular 
class of tasks is essentially determined by the latter rather 
than the former. The conclusion follows that many 
language characteristics are irrelevant to the alleged 
problem orientation. 

Iswim is an attempt at a general purpose system for 
describing things in terms of other things, that can be 
problem-oriented by appropriate choice of "primitives." 
So it is not a language so much as a family of languages, 
of which each member is the result of choosing a set of 
primitives. The possibilities concerning this set and what 
is needed to specify such a set are discussed below. 

Iswim is not alone in being a family, even after mere 
syntactic variations have been discounted (see Section 4). 
In practice, this is true of most languages that achieve 
more than one implementation, and if the dialects are well 
disciplined, they might with luck be characterized as 

Presented at an ACM Programming Languages and Pragmatics 
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1 There is no more use or men! ion of X in this paper — cognoscenti 
will nevertheless sense an undercurrent. A not inappropriate title 
would have been "Church without lambda." 



differences in the set of things provided by the library or 
operating system. Perhaps had Algol 60 been launched 
as a family instead of proclaimed as a language, it would 
have fielded some of the less relevant criticisms of its 
deficiencies. 

At first sight the facilities provided in Iswim will appear 
comparatively meager. This appearance will be especially 
misleading to someone who has not appreciated how much 
of current manuals are devoted to the explanation of 
common (i.e., problem-orientation independent) logical 
structure rather than problem-oriented specialties. For 
example, in almost every language a user can coin names, 
obeying certain rules about the contexts in which the 
name is used and their relation to the textual segments 
that introduce, define, declare, or otherwise constrain its 
use. These rules vary considerably from one language to 
another, and frequently even within a single language 
there may be different conventions for different classes of 
names, with near-analogies that come irritatingly close to 
being exact. (Note that restrictions on what names can 
be coined also vary, but these are trivial differences. When 
they have any logical significance it is likely to be perni- 
cious, by leading to puns such as Algol's integer labels.) 

So rules about user-coined names is an area in which 
we might expect to see the history of computer applica- 
tions give ground to their logic. Another such area is in 
specifying functional relations. In fact these two areas are 
closely related since any use of a user-coined name im- 
plicitly involves a functional relation; e.g., compare 
x(x+a) f{b+2c) 
where I = b + 2c where }{x) = x(x+a) 

Iswim is thus part programming language and part pro- 
gram for research. A possible first step in the research 
program is 1700 doctoral theses called "A Correspondence 
between x and Church's X-notation." 1 

2. The where -Notation 

In ordinary mathematical communication, these uses 
of 'where' require no explanation. Nor do the following: 

f(b+2c) + /(26-c) 

where f(x) = x(x+a) 

/(6+2c) + f(2b-c) 

where /(z) = x(x+a) 

and b = «/(tt+l) 

and c = v/(v+l) 

g(f where f(x) = ax 2 + bx + c, 

u/(u+l), 

v/{v+\)) 

where g(f, p, q) = /(p+2g, 2p-q) 
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A phrase of the form 'where definition' will be called a 
"where-clause." An expression of the form 'expression 
where-clause' is a "where-expression." Its two principal 
components are called, respectively, its "main clause" 
and its "supporting definition." To put 'where' into a 
programming language the following questions need 
answers. 

Linguistic Structure. What structures of expression 
can appropriately be qualified by a where-clause, e.g., 
conditional expressions, operand-listings, statements, 
declarations, where-expressions? 

Likewise, what structures of expression can appro- 
priately be written as the right-hand side (rhs) of a 
supporting definition? What contexts are appropriate for a 
where-expression, e.g., as an arm of a conditional ex- 
pression, an operator, the main-clause of a where-ex- 
pression, the left-hand side (Ihs) of a supporting definition, 
the rhs of a supporting definition? 

Syntax. Having answered the above questions, what 
are the rules for writing the acceptable configurations 
unambiguously? E.g., where are brackets optional or 
obligatory? or other punctuation? or line breaks? or in- 
dentation? Note the separation of decisions about struc- 
ture from decisions about syntax. (This is not a denial 
that language designers might iterate, like hardware 
designers who distinguish levels of hardware design.) 

Semantic Constraints on Linguistic Structure. In the 
above examples each main clause was a numerical ex- 
pression; i.e., given appropriate meanings for the various 
identifiers in it, it denoted a number. What other kinds of 
meaning are appropriate for a mainclause, e.g., arrays, 
functions, structure descriptions, print-formats? 

Likewise what kinds of meaning are appropriate for 
rhs' s of supporting definitions? Notice there is not a third 
question analogous to the third question above under 
linguistic structure. This is because a where-expression 
must mean the same kind of thing as its main clause and 
hence raises no new question concerning what contexts 
are meaningful. Notice also that the questions about 
meaning are almost entirely independent of those about 
structure. They depend on classifying expressions in two 
ways that run across each other. 

Outcome. What is the outcome of the more recondite 
structural configurations among those deemed admissible, 
e.g. mixed nests of where-expressions, function definitions, 
conditional expressions, etc.? 

Experimental programming has led the author to think 
that there is no configuration, however unpromising it 
might seem when judged cold, that will not turn up quite 
naturally. Furthermore, some configurations of 'where' 
that might first appear to reflect somewhat pedantic dis- 
tinctions, in fact provide close matches for current lan- 
guage features such as name/ value and own (see [2, 3]). 

All these questions are not answered in this paper. The 
techniques for answering them are outlined in Section 4. 

One other issue arises when 'where' is added to a 
programming language — types and specifications. A 



method of expressing these functionally is explained in 
[2]. It amounts to using named transfer-functions instead 
of class names like integer, i.e., writing 

where n = round{n) 

instead of the specification 

integer n 

Thus the use of functional notation does not jeopardize 
the determination of type from textual evidence. 

3. Physical ISWIM and Logical ISWIM 

Like Algol 60, Iswim has no prescribed physical 
appearance. Algol 60's designers sought to avoid commit- 
ment to any particular sets of characters or type faces. 
Accordingly they distinguish between "publication lan- 
guage," "reference language" and "hardware languages." 
Of these the reference language was the standard and was 
used in the report itself whenever pieces of Algol 60 
occurred. Publication and hardware languages are trans- 
literations of the reference language, varying according to 
the individual taste, needs and physical constraints on 
available type faces and characters. 

Such variations are different physical representations 
of a single abstraction, whose most faithful physical 
representation is the reference language. In describing 
Iswim we distinguish an abstract language called "logical 
Iswim," whose texts are made up of "textual elements," 
characterized without commitment to a particular physical 
representation. There is a physical representation suitable 
for the medium of this report, and used for presenting 
each piece of Iswim that occurs in this report. So this 
physical representation corresponds to "reference Algol 
60," and is called "reference Iswim," or the "Iswim 
reference representation," or the "Iswim reference lan- 
guage." 

To avoid imprecision one should never speak just of 
"Iswim," but always of "logical Iswim" or of "such- 
and-such physical Iswim." However, in loose speech, 
where the precise intention is clear or unimportant, we 
refer to "Iswim" without qualification. We aim at a more 
formal relation between physical and logical languages 
than was the case in the Algol 60. This is necessary since 
we wish to systematize and mechanize the use of different 
physical representations. 

4. Four Levels of Abstraction 

The "physical/logical" terminology is often used to 
distinguish features that are a fortuitous consequence of 
physical conditions from features that are in some sense 
more essential. This idea is carried further by making a 
similar distinction among the "more essential" features. 
In fact Iswim is presented here as a four-level concept 
comprising the following: 

(1) physical Iswim's, of which one is the reference 
language and others are various publication and hardware 
languages (not described here). 
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(2) logical Iswim, which is uncommitted as to char- 
acter sets and type faces, but committed as to the sequence 
of textual elements, and the grammatical rules for group- 
ing them, e.g., by parentheses, indentation and precedence 
relations. 

(3) abstract Iswim, which is uncommitted as to the 
grammatical rules of sequence and grouping, but com- 
mitted as to the grammatical categories and their nesting 
structure. Thus abstract Iswim is a "tree language" of 
which logical Iswim is one linearization. 

(4) applicative expressions (AEs), which constitute 
another tree language, structurally more austere than 
abstract Iswim, and providing certain basic grammatical 
categories in terms of which all of Iswim 's more numerous 
categories can be expressed. 

The set of acceptable texts of a physical Iswim is 
specified by the relations between 1 and 2, and between 
2 and 3. The outcome of each text is specified by these 
relations, together with a "frame of reference," i.e., a rule 
that associates a meaning with each of a chosen set of 
identifiers. 

These are the things that vary from one member of our 
language family to the next. The specification of the family 
is completed by the relation between abstract Iswim and 
AEs, together with an abstract machine that interpret 
AEs. These elements are the same for all members of the 
family and are not discussed in this paper (see [1, 2, 4]). 

The relationship between physical Iswim and logical 
Iswim is fixed by saying what physical texts represent 
each logical element, and also what layout is permitted in 
stringing them together. The relationship between logical 
Iswim and abstract Iswim is fixed by a formal grammar 
not unlike the one in the Algol 60 report, together with a 
statement connecting the phrase categories with the 
abstract grammatical categories. 

These two relations cover what is usually called the 
"syntax" or "grammar" of a language. In this paper 
syntax is not discussed beyond a few general remarks and 
a few examples whose meaning should be obvious. 

The relationship between abstract Iswim and AEs is 
fixed by giving the form of AE equivalent to each abstract 
Iswim grammatical category. It happens that these latter 
include a subset that exactly matches AEs. Hence this 
link in our chain of relations is roughly a mapping of 
Iswim into an essential "kernel" of Iswim, of which all the 
rest is mere decoration. 

5. Abstract ISWIM 

The texts of abstract Iswim are composite information 
structures called amessage's. The following structure 
definition defines 2 the class amessage in terms of a class 
called identifier. It also defines several functions for 
manipulating amessage's. These comprise the predicates 

4 WriliiiK .'i structure definition involves coining names for the 
various alternative formats of amessage's and their components. 
The only obscure coinage is "beet," which abbreviates "beta- 
redex," i.e.. "an expression amenable to rule <j3)"; see Section 7. 



demand, simple, infixed, etc; also the selectors body, rotor, 
leftarm, nee, etc; also (taking for granted certain un- 
formalized conventions concerning structure definitions) 
the constructors, consdemand, conscombination (elsewhere 
abbreviated to combine), consstandardadef , etc. Examples 
of reference Iswim are given alongside, against the right 
margin. 
An amessage is 

either a demand, and has [Print a+26 

a body which is an aexpression, 
or else a definition, [Def x=a+2b 

where rec 

an aexpression (aexp) is 
either simple, and has [C'Ath231" 

a body which is an identifier 
or a combination, in which case it has [sin(a+2b) 
a ralor, which is an aexp, or 
and a rand, which is an aexp, a + 26 

or conditional, in which case it is 

either two-armed, and has [p— >a+26 ; 2a— b 
a condition, which is an aexp, 
and a leftarm, which is an aexp, 
and a rightarm, which is an aexp, 
or one-armed, and has [g— >2a— 6 
a condition, which is an aexp, 
and an arm, which is an aexp, 
or a listing, and has [a+b, c+d, e+f 

a body which is an aexp-list, 
or beet, and has [x{x+\) where x = a + 26 

a mainclause, which is an aexp, or 
and a support let x = a + 26; x(x+l) 

which is an adef, 

and 

an adefinition (adef) is 
either standard, and has [x=a+2b 

a definee (nee), which is an abv, 

and a definiens (niens), which is an aexp, 
or functionform, and has [/(x) =x(x+l) 

a lejthandside (Ihs), 
which is an abv-list of length >2, 

and a righthandside (rhs), which is an aexp 
or programpoint, and has [pp f(x) =x(x+l) 

a body which is an adef, 
or circular, and has [rec f (n) = (n = 0)^1 ; raf (n — 1) 

a body which is an adef, 
or simultaneous, and has [x=a+2b and y = 2a — b 

a body, which is an adef-list, 
or beet, and has lf(y)=x(x+y) 

a mainclause , where x = a +26 

which is an adef, 

and a support, which is an adef. 
where an abv is 
either simple, and has 

a body, which is an identifier, 
or else, is an abv-list. [x, (y, z), w 

A program-point definition introduces a deviant kind 
of function. Applying such a function precipitates pre- 
mature termination of the where-expression containing 
it, and causes its result to be delivered as the value of the 
entire where-expression. 

Program-points are Iswm's, nearest thing to jumping. 
Assignment is covered as a particular case of an operator. 
For both of these the precise specification is in terms of the 
underlying abstract machine (see [2]). 
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6. Relationship to LISP 

Iswim can be looked on as an attempt to deliver Lisp 
from its eponymous commitment to lists, its reputation 
for hand-to-mouth storage allocation, the hardware 
dependent flavor of its pedagogy, its heavy bracketing, 
and its compromises with tradition. These five points are 
now dealt with in turn : 

(1) Iswim has no particular problem orientation. 
Experiments so far have been mainly in numerical work 
and language processing with brief excursions into "com- 
mercial" programming and elsewhere. No bias towards or 
away from a particular field of application has emerged. 

(2) Outside a certain subset (corresponding closely to 
Algol £0 without dynamic own arrays), Iswim needs 
garbage collection. An experimental prototype imple- 
mentation followed common Algol 60 practice. It used 
dynamic storage allocation with two sources, one LIFO 
and the other garbage collected, with the intention that 
the LIFO source should take as big a share as possible. 

However, as with Algol 60, there is a latent potential 
for preallocating storage in certain favorable and com- 
monly useful situations. Compared with Lisp the chief 
amelioration of storage allocation comes out of a mere 
syntactic difference, namely, the use of where (oi let' 
which is exactly equal in power and program structure). 
This provides a block-structure not dissimilar in textual 
appearance from Algol 60's, though it slips off the pen 
more easily, and is in many respects more general. 

(3) Lisp has some dark corners, especially outside 
"pure Lisp," in which both teachers and programmers 
resort to talking about addresses and to drawing storage 
diagrams. The abstract machine underlying Iswim is 
aimed at illuminating these corners with a minimum of 
hardware dependence. 

(4) The textual appearance of Iswim is not like Lisp's 
S-expressions. It is nearer to Lisp's If -expressions (which 
constitute an informal language used as an intermediate 
result in hand-preparing Lisp programs). Iswim has the 
following additional features: 

(a) "Auxiliary" definitions, indicated by let' or 'where', 
with two decorations: 'and' for simultaneous definitions, 
and 'rec' for self-referential definitions (not to be mistaken 
for a warning about recursive activation, which can of 
course also arise from self-application, and without self- 
reference). 

(b) Infixed operators, incorporated systematically. A 
logical Iswim can be defined in terms of four unspecified 
parameters: three subsets of the class of identifiers, for use 
as prefixed, infixed and postfixed operators; and a prec- 
edence relation defined over the union of these subsets. 

(c) Indentation, used to indicate program structure. A 
physical Iswim can be defined in terms of an unspecified 
parameter: a subset of phrase categories, instances of 
which are restricted in layout by the following rule called 
"the offside rule." The southeast quadrant that just con- 
tains the phrase's first symbol must contain the entire 
phrase, except possibly for bracketed subsegments. This 



rule has three important features. It is based on vertical 
alignment, not character width, and hence is equally 
appropriate in handwritten, typeset or typed texts. Its 
use is not obligatory, and use of it can be mixed freely with 
more conventional alternatives like punctuation. Also, it 
is incorporated in Iswim in a systematic way that admits 
of alternatives without changing other features of Iswim 
and that can be applied to other languages. 

(5) The most important contribution of Lisp was not 
in listprocessing or storage allocation or in notation, but 
in the logical properties lying behind the notation. Here 
Iswim makes little improvement because, except for a few 
minor details, Lisp left none to make. There are two 
equivalent ways of stating these properties. 

(a) Lisp simplified the equivalence relations that 
determine the extent to which pieces of program can be 
interchanged without affecting the outcome. 

(b) Lisp brought the class of entities that are denoted 
by expressions a programmer can write nearer to those 
that arise in models of physical systems and in mathe- 
matical and logical systems. 

These remarks are expanded in Sections 7 and 8. 
7. The Characteristic Equivalences of ISWIM 

For most programming languages there are certain 
statements of the kind, "There is a systematic equivalence 
between pieces of program like this, and pieces like that," 
that nearly hold but not quite. For instance in Algol 60 
there is a nearly true such statement concerning procedure 
calls and blocks. 

At first sight it might appear pedantic to quibble about 
such untidiness — "What's the point of having two different 
ways of doing the same thing anyway? Isn't it better to 
have two facilities than just one?" The author believes 
that expressive power should be by design rather than 
accident, and that there is great point in equivalences that 
hold without exception. It is a platitude that any given 
outcome can be achieved by a wide variety of programs. 
The practicability of all kinds of program-processing 
(optimizing, checking satisfaction of given conditions, 
constructing a program satisfying given conditions) 
depends on there being elegant equivalence rules. For 
Iswim there are four groups 3 , concerning: 

(1) the extent to which a subexpression can be replaced 
by an equivalent subexpression without disturbing the 
equivalence class of the whole expression. Without this 
group the other rules would be applicable only to complete 
expressions, not to subexpressions. 

(2) user-coined names, i.e., in definitions and, in particu- 
lar, function definitions. 

(3) built-in entities implicit in special forms of ex- 
pression. The only instances of this in Iswim are conditional 
expressions, listings and self-referential definitions. 

(4) named entities added in any specific problem- 
orientation of Iswim. 

3 To facilitate subsequent discussion each rule is preceded 
by a name, e.g., "(m)", "W", etc. These are chosen to conform 
with precedents in Curry's Combinatory Logic. 
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Group 1 

( M ) If L = V then h (M) s £' (M) 

« If M = M' then i (M) = L (M') 

(/) If M = ilf' then (L, - ■ ■ , M, ■ ■ ■ , N)=(L, ■ ■ ■ , M', ■ ■ -N) 

(»") If L = 1/ then (L->M; jV) = (I/— M, N) 

(v" r ) If M = ilf' then (L->M; A') = (L— M'; A') 

(*") If A r = A r ' then (L->M; A') = (Zr-»Jf; N') 

(v") If Af = M' then (L where x = M) = (L where x=M') 

The significant omissions here are the main-clause in the 
last case above, the rhs of a function definition "f(x) = M" 
and of a circular definition "rec x = M". 

Group 2 

(let) let a; = M; L = L where x = M 

(/') /(») = L m f = (g where ff(a)=i) 

/(a, 6, c)(x, y) = L = f(a,b,c) = where 3(2,?/) = I) 
and so on for each shape of left-hand side 
(/) (/ where f(x) =L) M = L where x = M 
(/3') (x=L) where y = M = x = (L where y — M) 
(D') x — L and y = M and s . • . and z = N 

s •••,2) = (i, M, ■■■,N) 

Rules (/'), 03') , CD'), together with (F) below, enable 
any definition to be "standardized," i.e., expressed in a 
Ihs/rhs form, in which the Ihs is precisely the definee. Thus 
a nonstandard definition can be transformed so as to be 
amenable to rules (i>") and (/3) (see Group 2'). 

Group 2' 



Q9) L where x 



= Subst 



where "Subst ^ C" means roughly the expression resulting 

from substituting A for B throughout C. Here V may be 
any list-structure of distinct identifiers, provided that 
'M' has structure that fits it. 

This rule is the most important, but it has only limited 
validity, namely, within the "purely functional" subset of 
Iswim that results from not using the program-point 
feature or assignment. 

Its importance lies in a variant of a famous theorem of 
mathematical logic, the Church-Rosser theorem. This 
concerns the possibility of eliminating 'where' from an 
expression by repeatedly applying the rules stated above, 
including crucially The theorem ensures that if there 
are several ways of doing this they all reach the same 
result. 

The author thinks that the fruitful development to 
encompass all Iswim will depend on establishing "safe" 
areas of an Iswim expression, in which imperative features 
can be disregarded. The usefulness of this development 
will depend on how successfully Iswim's nonimperative 
features supersede conventional programming. 

Group 3 



(-) 
(->') 
(->") 



true — > M; N 
false — > M : N 



= P —> M : undefined 



{undefined) undefined = selfapply (selfapply) 

where selfapply (J) = /(/) 
(Y) rec X = L = x = (L where rec x = L) 

(D") (x, ...,«) - M - (x, ■■■,z) = 

null (t k w) — > 

hw, ■ ■ ■ , h(t^w) 
where to = M 

(for k > 2) 
(x, (u, v),z) = M = (x, (u, v), z) = 
null (V>w) -* 
h(w), 

(null (t*w') -> 

fc(w'), *(<(»')) 
where w' = h(t(w))) 
h(trw) 
where w = M 
and so on for each shape of definee 
(null) null (nullist) = true 

(null') null (L u ■••,!*) = false 

where (x, ■ ■ • , z) 

= U, ■ ■ ■ , L k (k > 2) 

(A) h(L ly ■ ■ ■ , L t ) =x 

where (x, ■ ■ ■ , z) 

= Lj, L k (k > 2) 

(0 t(L u ---,L k ) 

where (x, ?/, • ■ •, z) 

= U,---,L k (k > 3) 

(«') L2)) = 

where (a;, J/) = ^2 

The rules about listings may appear willfully indirect. 
The more natural transformations are those effected by 
applying, for example, (D") then (/3). But these would 
have suffered the same limited validity as (0). In their 
above slightly cautious formulation the validity of (D"), 
etc. is unrestricted, and the more powerful equivalences 
that hold for nonimperative expressions arise entirely 
from 03). 

Group 4 

A problem-orientation of Iswim can be characterized 
by additional axioms. In the simplest case such an axiom 
is an Iswim definition. The resulting modification is called 
a "definitional extension" of the original system. 

In more elaborate cases axioms may mutually constrain 
a group of identifiers; e.g. the following rule for equality 
among integers: 

( = ) Suppose L and M are Iswim written integers 
(i.e., strings of digits); then either one or the other of the 
following holds: 



according as L and M differ at most in lefthand zeros, or 
not. 

Another example, presented even less formally, is the 
structure definition for abstract Iswim. 

Group 1 above makes no provision for substitutions 
within expressions that are qualified by a supporting 
definition or are used to define a function. However, such 
a substitution is legitimized as long as it does not involve 
the definees or variables, by encasing it within applications 
of rule (8) and its inverse (with any other rules that might 
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be needed to produce something that is amenable to (j3), 
i.e., a beet with a standard definition). 

Equivalence rules can be used to prove things about the 
system. For example, the reader will readily verify that 
the equivalence of 

f (6) where rec f(n) = (n = 0) -> 1; nf 

and 

6 (/(5) where rec / (n) = (n=0) lj nf (n-1)) 

can be established with the following steps : 

(/'), (Y), (/3), (F), ((3), (I), (=), (0) backwards, (F) backwards, 
(/') backwards. 

in this sequence we omit the auxiliary applications of (|8), 
etc. that are needed at almost every step to legitimize the 
substitution. 

8. Application and Denotation 

The commonplace expressions of arithmetic and algebra 
have a certain simplicity that most communications to 
computers lack. In particular, (a) each expression has a 
nesting subexpression structure, (b) each subexpression 
denotes something (usually a number, truth value or 
numerical function), (c) the thing an expression denotes, 
i.e., its "value", depends only on the values of its sub- 
expressions, not on other properties of them. 

It is these properties, and crucially (c), that explains 
why such expressions are easier to construct and under- 
stand. Thus it is (c) that lies behind the evolutionary 
trend towards "bigger righthand sides" in place of strings 
of small, explicitly sequenced assignments and jumps. 
When faced with a new notation that borrows the func- 
tional appearance of everyday algebra, it is (c) that gives 
us a test for whether the notation is genuinely functional 
or merely masquerading. 

The important feature of Iswim's equivalence rules is 
chat they guarantee the same desirable properties to 
Iswim's nonimperative subset. We may equate "abstract 
object" with "equivalence class," and equate "denotes" 
with "is a member of." Then the properties (/*) and {v) 
ensures anologies of (c) above. They state that the value 
of an operator/operand combination depends only on the 
values of its component subexpressions, not on any other 
aspects of them. 

Thus conditions (/*) and (v) are equivalent to the 
existence of a dyadic operation among the abstract ob- 
jects; we call this operation "application." 

The terminology of "abstract objects," "denoting" and 
"application" is frequently more convenient than that of 
equivalence relations. For example, it suggests another 
way of characterizing each problem-orientation of Iswim. 
We can think of a set of abstract objects with a partially 
defined dyadic "application" operation and a monadic 
"designation" operation that associates a "primitive" 
abstract object with each of some chosen set of names, 
called the "constants" of the special system. 

Consider for example a programming language that 



contains expressions such as 

'wine' 

Anyone with a generous ontology will admit that 
this 6-character expression denotes the 4-character-string 
wine 

For such a person its use in the language is characterized 
by 

• the objects that it is applicable to, and the object it 
produces in each case (e.g., strings might be used like 
vectors, whose application to an integer produces an 
item of the string). 

• The objects that it is amenable to, and the object it 
yields in each case (e.g., prefixing, appending, selection, 
etc.). 

The sceptic need not feel left out. He just has to talk, a 
bit more clumsily, about 

'wine' 

being in the equivalence class that also contains 

concatenate ('wi' , 'ne') 

and 

append (jifthlt'ttcrvf (roma nalphabeJ) , 
(threeletterstemof ('winter')) 

Then he goes on to speak of the equivalence class of 
expressions that can serve as operand or operator to any 
of the above, and the equivalence class of the resulting 
operator/ operand combination. 

9. Note on Terminology 

Iswim brings into sharp relief some of the distinctions 
that the author thinks are intended by such adjectives as 
procedural, nonprocedural, algorithmic, heuristic, impera- 
tive, declarative, functional, descriptive. Here is a sug- 
gested classification, and one new word. 

First, none of these distinctions are concerned with the 
use of pidgin English rather than pidgin algebra. Any 
pidgin algebra can be dressed up as pidgin English to 
please the generals. Conversely, it is a special case of the 
thesis underlying Iswim that any pidgin English that has 
so far been implemented can be stripped to pidgin algebra. 
There is nevertheless an important possibility of having 
languages that are heuristic on account of their "applica- 
tive structure" being heuristic. 

An important distinction is the one between indicating 
what behavior, step-by-step, you want the machine to 
perform, and merely indicating what outcome you want. 
Put that way, the distinction will not stand up to close 
investigation. I suggest that the conditions (a-c) in Section 
8 are a necessary part of "merely indicating what outcome 
you want." The word "denotative" seems more appro- 
priate than nonprocedural, declarative or functional. The 
antithesis of denotative is "imperative." Effectively 
"denotative" means "can be mapped into Iswim without 
using jumping or assignment," given appropriate primi- 
tives. 
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It follows that functional programming has little to do 
with functional notation. It is a trivial and pointless task 
to rearrange some piece of symbolism into prefixed opera- 
tors and heavy bracketing. It is an intellectually demand- 
ing activity to characterize some physical or logical 
system as a set of entities and functional relations among 
them. However, it may be less demanding and more 
revealing than characterizing the system by a conventional 
program, and it may serve the same purpose. Having 
formulated the model, a specific desired feature of the 
system can be systematically expressed in functional 
notation. But other notations may be better human 
engineering. So the role of functional notation is a standard 
by which to describe others, and a standby when they fail. 

The phrase "describe in terms of" has been used above 
with reference to algorithmic modes of expression, i.e., 
interchangeably with "express in terms of." In this sense 
"3 + 4" is a description of the number 7 in terms of the 
numbers 3 arid 4. This conflicts with current use of the 
phrase "descriptive languages," which appears to follow 
the logicians. For example, a language is descriptive in 
which the machine is told 

Print the x such that x 2 — x — 6 = 0 A x > 0 

Such a classification of languages (as opposed to merely 
expressions within languages) is useless, and even harmful 
by encouraging stupidly restrictive language design, if it 
excludes the following : 

Print square (the x such that x 2 — x — Q = 0Ax>0) 
Print u(u+l) 

■where u = the x such that x 2 — x — 6 = 0 A i > 0. 
Print /(l, -1, 6) 

where f(a, b, c) = the x such that ax 2 + bx + c = 0 A x >0 

On the other hand it might reasonably exclude 
Print solepositivezeroof (1, —1, —6) 

where soleposilivezerooj happens to be a library function. 

The author therefore suggests that there is a useful 
distinction that can be made here concerning languages. 
Consider the function i, which operates on a class (or 
property) having a sole member (or instance), and trans- 
forms it into its sole member. We are interested in whether 
or not a language permits reference to i, with more or 
less restricted domain. 

For example the above programs become: 

Print i(p where p(x) =x 2 —x— 6 A x > 0) 

Print square (i(p where p(x)=x 2 — x— 0 A i > 0)) 

Print u(u+l) 

where u = i (p where p(x) =x 2 — x — 6 A x > 0) 
Print /(l, -1, -6) 

where / (a, b, c) = i(p where p(x) =ax 2 +bx+c A x > 0) 

More precisely, the distinction hinges on whether, when 
"applicative structure" is imputed to the language, it can 
be done without resorting to i, or to primitives in terms of 
which i can be defined. 

This discussion of i reveals the possibility that primitives 
might be sensationally nonalgorithmic. So the algorithmic/ 
heuristic distinction cuts across the denotative/imperative 



(i.e., nonprocedural/procedural) distinction. On the other 
hand if limited forms of i can be algorithmized, they still 
deserve the term "descriptive." So this factor is also 
independent. 

10. Eliminating Explicit Sequencing 

There is a game sometimes played with Algol 60 
programs — rewriting them so as to avoid using labels and 
go to statements. It is part of a more embracing game — 
reducing the extent to which the program conveys its 
information by explicit sequencing. Roughly speaking this 
amounts to using fewer and larger statements. The game's 
significance lies in that it frequently produces a more 
"transparent" program — easier to understand, debug, 
modify and incorporate into a larger program. 

The author does not argue the case against explicit 
sequencing here. Instead he takes as point of departure the 
observation that the user of any programming language is 
frequently presented with a choice between using explicit 
sequencing or some alternative feature of the language. 
Furthermore languages vary greatly in the alternatives 
they offer. For example, our game is greatly facilitated by 
Algol 60's conditional statements and conditional ex- 
pressions. So the question considered here is: What other 
such features are there? This question is considered be- 
cause, not surprisingly, it turns out that an emphasis on 
describing things in terms of other things leads to the 
same kind of requirements as an emphasis against explicit 
sequencing. 

Though Algol CO is comparatively favorable to this 
activity, it shares with most other current languages 
certain deficiencies that severely limit how far the game 
can go. The author's experiments suggest that two of the 
most needed features are: 

• Treat a listing of expressions as a special case of the 
class of expressions, especially in the arms of a conditional 
expression, and in defining a function. 

• Treat argument lists as a special case of lists. So a 
triadic function can have its arguments supplied by a 
conditional whose arms are 3-listings, or by application of 
a function that produces a 3-list. A similar situation arises 
when a 3-listing occurs as a definee. (Even Lisp trips up 
here, over lists of length one.) 

To clarify their practical use, here are some of the 
steps by which many a conventional Algol 60 or PL/1 
program can be transformed into an Iswim program that 
exploits Iswim's nonimperative features. 

(1) Rewrite the program so as to use two-dimensional 
layout and arrows to illuminate the explicit sequencing, 
i.e., as a flowchart with algebraic steps. Rearrange this to 
achieve the least confusing network of arrows. 

(2) Apply the following changes repeatedly wherever 
they are applicable : 

(a) Replace a string of independent assignments by one 
multiple assignment. 

(b) Replace an assignment having purely local signifi- 
cance by a where-clause. 

(c) Replace procedures by type-procedures (possibly 
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with multiple type), and procedure statements by assign- 
ment statements. 

(d) Replace conditional jumps by conditional state- 
ments having bigger arms. 

(e) Replace a branch whose arms have assignees in 
common by an assignment with conditional right-hand 
side. 

(f) Replace a join by two calls for a procedure. 

It should be observed that translating into Iswim does 
not force such rearrangements; it merely facilitates them. 
One interesting observation is that the most recalcitrant 
uses of explicit sequencing appear to be associated with 
success/failure situations and the action needed on failure. 

Section 2 discussed adding 'where' to a conventional 
programming language. Theory and experiment both 
support the opposite approach, that taken in Lisp, of 
adding imperative features to a basically nonimperative 
language. One big advantage is that the resulting language 
will have a nonimperative subset. 

The special claim of Iswim is that it grafts procedural 
notions onto a purely functional base without disturbing 
many of the desirable properties. The underlying ideas 
have been presented in [2]. This paper can do no more than 
begin the task of explaining llieir practical significance. 

11. Conclusion 

The languages people use to communicate with com- 
puters differ in their intended aptitudes, towards either a 
particular application area, or a particular phase of com- 
puter use (high level programming, program assembly, 
job scheduling, etc). They also differ in physical appear- 
ance, and more important, in logical structure. The ques- 
tion arises, do the idiosyncracies reflect basic logical 
properties of the situations that are being catered for? 
Or are they accidents of history and personal background 
that may be obscuring fruitful developments? This 
question is clearly important if we are trying to predict or 
influence language evolution. 

To answer it we must think in terms, not of languages, 
but of families of languages. That is to say we must 
systematize their design so that a new language is a point 
chosen from a well-mapped space, rather than a laboriously 
devised construction. 

To this end the above paper has marshalled three 
techniques of language design: abstract syntax, axiomatiza- 
tion, and an underlying abstract machine. 

It is assumed that future calls on language development 
cannot be forstalled without generalizing the alternatives 
to explicit sequencing. The innovations of "program- 
points" and the "off-side rule" are directed at two of the 
problems (respectively in the areas of semantics and 
syntax) that must consequently be faced. 

Acknowledgments. The author is grateful for helpful 
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DISCUSSION 

Naur: Regarding indentation, in many ways I am in sympathy 
with this, but I believe that if it came about that this notation 
wen; used for very wide communication and also publication, you 
would regret it because of the kind of rearrangement of manu- 
scripts done in printing, for example. You very frequently run 
into the problem that you have a wide written line and then 
suddenly you go to the VommunirathmH <>/ the ACM and radically, 
perhaps, you have to compress it. The printer will do this in any 
way he likes; he is used to having great freedom here and he will 
foul up your notation. 

Landin: I have great experience with this. (Laughter) I think 
I am probably the only person who has run through three versions 
of I he galley proofs for the Communications of the ACM . However, 
I think that next time I could do better, and I think it is worth 
looking into. At any rate, the principle that I have described here 
is a good deal better than some that one might think of; for example 
it does not depend on details of character width, character by 
character — it is just as good handwritten as it is printed. Secondly, 
limiting the breadth of the page, I agree with you, needs more 
consideration. By the time I got through with the particular 
example I am talking about, by getting it printed, I had devised 
what f thought was a fairly reasonable method of communicating 
the principles that have been used in indentation. 

Floyd: Another objection that I think is quite serious to 
indentation is that while it works on the micro-scale — that is, one 
page is all right — when dealing with an extensive program, turning 
from one page to the next there is no obvious way of indicating 
how far indentation stretches because there is no printing at all to 
indicate how far you have indented. I would like you to keep that 
in mind. 

Landin: Yes, I agree. In practice I deal with this by first making 
the page breaks in sensible places. 

Floyd: That's all right as long as you don't have an indented 
region which is simply several pages long. 

Landin: Well in that case the way I did it was to cut down the 
number of carryover levels to about four or five from one page to 
another. You can at least make it simpler when you are hand- 
writing by putting some kind of symbols at the bottom of the page 
and top of the continuation. 

Floyd: Even if you regard your indentation spaces as characters 
there still doesn't seem to be any way — in fact, I am fairly sure 
there is no way — of representing the indentation conventions 
within a phrase-structure grammar. 

Landin: Yes, but some indentation conventions can be kept 
within phrase structure grammars by introducing two terminal 
symbols that are grammatically like parentheses, but are textually 
like typewriter keys for setting and clearing tabulation positions. 
More precisely, the textual representation of the second of these 
symbols can be explained as the following sequence of typewriter 
actions: 1) line-feed; 2) back-space as far as the right-most tab 
position that is still currently active; 3) clear tab position; and 
4) do step 2 again. 

While this fits some indentation conventions, the one I propose 
is too permissive to be included. For my language I have written 
a formal grammar that is not phrase structure and includes one 
departure that meets this problem. 
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Leavenworth: I should like to raise the question of eliminating 
explicit jumps, I mean of using recursion as against interation. 

Landin: It seems to me that there are rather a small number of 
functions which you could use if you were writing a Lisp program 
in the places where ordinary programs would use iterations, and 
that if you were to use these the processor might do as well as if 
you had written a loop. For example, iterate (m, /, x) might 
apply /, m times to x with the result f m (x). This is the simplest 
kind of loop I know and the function iterate provides a purely 
functional notation for this rather simple kind of loop. If a lot of 
familiar types of loop can be represented by a few functions which 
could be defined recursively, I think it is sensible to take these as 
primitive. Another such function is while (p, f, x) which goes on 
applying / to x until the predicate p becomes false. 

Strachey: I must just interpolate here something which is a bit 
of advertising I suppose. Nearly all flic linguistic features, such as 
where and while and and and recursive, that Peter Landin has 
been talking about »n; incorporated as an integral part of a pro- 
gramming language being developed at Cambridge and London 
called CPL. In fact the where clauses are a very important feature 
of this' language. 

Irons: I have put together a program which uses some of these 
features and which has a standard output which prints the pro- 
gram in an indented manner. If it runs off the right end of the page, 
it produces another page to go on the right, and so forth. While 
certainly then; are some situations that occur when it would be a 
bit awkward to make the paper go around the room, I have found 
that in practice, by and large it is true that this is a very profit- 
able way of operating. 

Strachey: I should like to intervene now and try to initiate a 
slightly more general discussion on declarative or descriptive 
languages and to try to clear up some points about which there is 
considerable confusion. I have called the objects I am trying to 
discuss DLs because I don't quite know what they are. Here are 
some questions concerning DLs: (1) What are DLs? (2) What is 
their relationship to imperative languages? (3) Why do we need 
DLs? (4) How can we use them to program? (5) How can we 
implement them? (6) How can we do this efficiently? (7) Should we 
mix DLs with imperative languages? 

It seems to me that what I mean by DLs is not exactly what 
other people mean. I mean, roughly, languages which do not 
contain assignment statements or jumps. This is, as a matter of 
fact, not a very clear distinction because you can always disguise 
the assignments and the jumps, for that matter, inside other state- 
ment forms which make them look different. The important 
characteristic of DLs is that it is possible to produce equivalence 
relations, particularly the rule for substitution which Peter 
Landin describes as (/3) in his paper. That equivalance relation, 
which appears to be essential in almost every proof, does not 
hold if you allow assignment statements. The great advantage 
then of DLs is that they give you some hope of proving the equi- 
valence of program transformations and to begin to have a calculus 
for combining and manipulating them, which at the moment we 
haven't got. 

I suggest that an answer to the second question is that DLs form 
a subset of all languages. They are an interesting subset, but one 
which is inconvenient to use unless you are used to it. We need 
them because at the moment we don't know how to construct 
proofs with languages which include imperatives and jumps. 

How should we use them to program? I think this is a matter of 
learning a new programming technique. I am not convinced that 
all problems are amenable to programming in DLs but I am not 
convinced that there arc any which are not either; I preserve an 
open mind on this point. It is perfectly true that in the process of 
rewriting programs to avoid labels and jumps, you've gone half 
the way towards going into DLs. When you have also avoided 
assignment statements, you've gone the rest of the way. With 
many problems yen can, in fact, go the whole way. Lisp has no 



assignment statements and it is remarkable what you can do with 
pure Lisp if y r ou try. If you think of it in terms of the implementa- 
tions that we know about, the result is generally intolerably 
inefficient — but then that is where we come to the later questions. 

How do we implement them? There have not been many at- 
tempts to implement DLs efficiently, I think. Obviously, it can be 
done fairly straightforwardly by an interpretive method, but this 
is very slow. Methods which compile a runable program run into a 
lot of very interesting problems. It can be done, because DLs are 
a subset of ordinary programming languages; any programming 
language which has sufficient capabilities can cope with them. 
There are problems, however: we need entities whose value is a 
function — not the application of a function but a function — and 
these involve some problems. 

How to implement efficiently is another very interesting and 
difficult problem. It means, I think, recognizing certain subsets 
and transforming them from, say, recursions into loops. This can 
certainly be done even if they have been written in terms of 
recursions and not, as Peter Landin suggested, in terms of already 
transformed functions like iterate or while. 

I think the last question, "Should DLs be mixed with impera- 
tive languages?", clearly has the answer that, they should, be- 
cause at the moment we don't know how to do everything in pure 
DLs. If you mix declarative and imperative features like this, you 
may get an apparently large programming language, but the 
important thing is that it should be simple and easy to define a 
function. Any language which by mere chance of the way it is writ- 
ten makes it extremely difficult to write compositions of functions 
and very easy to write sequences of commands will, of course, in an 
obvious psychological way, hinder people from using descriptive 
rather than imperative features. In the long run, I think the effect 
will delay our understanding of basic similarities, which underlie 
different sorts of programs and different ways of solving problems. 

Smith: As I understand the declarative languages, there has to 
be a mixture of imperative and descriptive statements or no com- 
putation will take place. If I give you a set of simultaneous equa- 
tions, you may say "yes?", meaning well, what am I supposed to 
do about it, or you may say "yes", meaning yes I understand, but 
you don't do anything until I say "now find the values of the vari- 
ables." In fact, in a well-developed language there is not just one 
question that I can ask but a number of questions. So, in effect, the 
declarative statements are like data which you set aside to be used 
later after I give you the imperatives, of which I had a choice, 
which get the action. 

Strachey: This is a major point of confusion. There are two ideas 
here and I think we should try to sort them out. If you give a 
quadratic equation to a machine and then say "print the value of 
x", this is not the sort of language that I call a DL. I regard it as 
an implicit language — that is, one where you give the machine the 
data and then hope that it will be smart enough to solve the prob- 
lem for you. It is very different from a language such as Lisp, 
where you define a function explicitly and have only one impera- 
tive, which says "evaluate this expression and print the result." 

Abrahams: I've done a fair amount of programming in Lisp, 
and there is one situation which I feel is symptomatic of the times 
when you really do want an imperative language. It is a situation 
that arises if you are planning to do programming in pure Lisp and 
you find that your functions accumulate a large number of argu- 
ments. This often happens when you have a number of variables 
and you are actually going through a process and at each stage of 
the process you want to change the state of the world a little bit — 
say, to change one of these variables. So you have the choice of 
either trying to communicate them all, or trying to do some sort 
of essentially imperative action that changes one of them. If you 
try to list all of the transitions from state to state and incorporate 
them into one function, you'll find that this is not really a very 
natural kind of function because the natures of the transitions 
are too different. 
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Landin: I said in my talk that Lisp had not gone quite all the 
way and I think that this difficulty is connected with going all the 
way. If we write a function definition where the right-hand side is 
a listing of expressions such as 

F(x) = E lt E t ,E, 

then we can say that this function will produce a three-list as its 
result. If now we have another function G(x, y, z) = E, on some 
occasion we might have an expression such as (JUr. lr, c 2 > and we 
often feel that we should be able to write G(F(t)), and another 
example which should be allowed is 

G{fl>b-*E l ,E il E 3 else E t , E s , E,). 

I am not quite sure but I think you can gel around your problem 
by treating every function as if it were in fact monadic and had 
a single argument which was the list structure you are trying to 
process. 

Abrahams: This is a difficulty in other programming languages 
too; you cannot define a function of an indefinite number of argu- 
ments. 

Naur: I still don't understand this distinction about an im- 
plicit language. Does it mean that whenever you have such a 
language there is a built-in feature for solving equations? 

Abrahams: I think the point is whether you are concerned with 
the problem or are concerned with the method of solution of the 
problem. 

Ingerman: I suggest that in the situation where you have speci- 
fied everything that you want to know, though the exact sequence 
in which you evoke the various operations to cause the solution is 
left unspecified, then you have something which is effectively a 
descriptive language; if you have exactly the same pieces of in- 
formation, surrounded with promises that you will do this and 
then this, then you have an imperative language. The significant 
point, is that it is not all or nothing but there is ;i scale and while 
it is probably pretty simple to go all the way with imperatives, 



the chances of being able to get all the way descriptive is about 
zero, but there is a scale and we .should recognize this scale. 

Smith: I think that there is a confusion between implicit or 
explicit on the one hand and imperative or declarative on the 
other. These are two separate distinctions and can occur in all 
combinations. For instance, an analog computer handles implicit 
declaratives. 

Young: 1 think it is fairly obvious that you've got to have the 
ability for sequencing imperatives in any sort of practical lan- 
guage. There are many , many cases in which only a certain se- 
quence of operations will produce the logically correct results. 
So that we cannot have a purely declarative language, we must, 
have a general purpose one. A possible definition of a declarative 
language is one in which I can make the statements (a), (b), (c) 
and (d) and indicate whether I mean these to be taken as a se- 
quence or as a set; that is, must, they be performed in a particular 
order or do I merely mean that so long as they are all performed, 
they may be performed in any sequence at any time and whenever 
convenient for efficiency. 

Strachey: You can, in fact, impose an ordering on a language 
which doesn't have the sequencing of commands by nesting the 

Landin: The point is that when you compound functional ex- 
pressions you are imposing a partial ordering, and when you de- 
compose this into commands you are unnecessarily giving a lot of 
information about sequencing. 

Strachey: One inconvenient thing about a purely imperative 
language is that you have to specify far too much sequencing. For 
example, if you wish to do a matrix multiplication, you have to do 
n z multiplications. If you write an ordinary program to do this, 
you have to specify the exact sequence which they are all to be 
done. Actually, it doesn't matter in what order you do the multi- 
plications so long as you add them together' in the right groups. 
Thus the ordinary sort of imperative language imposes much too 
much sequencing, which makes it very difficult to rearrange if you 
want to make things more efficient. 
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A descriptive scheme for classes of pictures based on label- 
ing techniques using parallel processing algorithms was pro- 
posed by the author some years ago. Since then much work 
has been done in applying this to bubble chamber pictures. 
The parallel processing simulator, originally written for an 
IBM 7094 system, has now been rewritten for a CDC 3600 
system. This paper describes briefly the structure of syntactic 
descriptive models by considering their specific application to 
bubble chamber pictures. How the description generated in 
this phase can be embedded in a larger "conversation" pro- 
gram is explained by means of a certain specific example that 
has been worked out. A partial generative grammar for 
"handwritten" English letters is given, as are also a few com- 
puter-generated outputs using this grammar and the parallel 
processing simulator mentioned earlier. 
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1. Introduction 

Recent active interest in the area of graphic data-based 
"conversation programs" 1 has pointed up the urgent need 
for sophisticated picture processing models in a convincing 
manner. Kirsch [2] has very ably argued that "from the 
point of view of computer information processing, the 
important fact about natural language text and pictures 
is that both have a syntactic structure which is capable of 
being described to a machine and of being used for purposes 
of interpreting the information within a data processing- 
system." "The problem of how to describe the syntactic 
structure of text and pictures and how to use the syntactic 
description in interpreting the text and pictures" has been 
tackled in a certain specific way by Kirsch and his co- 
workers. (For other references, see [9].) 

1 See [9] for a good survey of work accomplished and in progress 
in this area, as well as in the general field of "English question- 
answer" programs. 
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